finding field in XSLT

OK, I have a DCR with replicants of translated content. So I do a foreach, trying to compare the Root/TranslatedContent/language to a variable ($locale) and use that data&colon;

[php]

[/php]

No data is presented. if I use:

[php]

[/php]

it works fine (for the 1st language)

So I assume it is in my xsl:if test=

Can anyone point me in the right direction ?

Andy

Find more posts tagged with

Comments

Crsb

Could you show sample DCR structure and where you define $dcr and $locale?

nipper

$dcr is the DCR dataum (this is a SP page using a template)

When I put this in the XSL:
[php]

----
[/php]

then I see -en_US--en_US- in the source

so I am confident i am pointing to the correct data.

Also, when I use TranslatedContent[2] I get the French content. So something is hosed with my xsl:if

Adam Stoller

You do know that XSLT variables are essentially set-once-then-readonly right? (w3schools)
You cannot change the value of the variable after it is created (although at least one person seems to suggest otherwise - down near bottom of page) - so I don't think your little for-loop is going to work the way you envisioned.

Instead I think you have to do something like pass the information as a parameter to another 'function' / section of the xslt code in order to do the kind of branching that I think you're trying to do.

Crsb

I don't see anything wrong with your syntax, so i can't think of much without seeing a sample DCR. if you think the problem might be with the if statement, then try.
[php]

[/php]

Also it will help adding some "print statements" to see what is being processed.

[php]

locale:
language:
title:

[/php]

vpatel

Post your XML and full XSL.

nipper

I made a test case to show, this is a DCR being read by LiveSite. But I figure if I can get it working in FormsPub I can get it working in SP.

Inlines were not working, now attaching.

The plan is to loop through the TranslatedContent container, looking for a specific language (for the example set in the DCR) and grabbing the title, body and image.

DCR, hard coded XSL and xsl:choose (non working) XSL attached. I also tried a for-each loop with an if, no luck

Crsb

This might not be the best xsl code, but test it and see if it works for you, it seems to work for me. if it does what you want it to do then use it as starting point.
as you might notice, the only difference between the code for xsl PT and code for SP component is that we start with "Root" in PT but with "/Properties/Data/Datum[@Name='DCR Demo']/DCR/Root" in SP component.

DCR content:
[php]

en_US

en_US
What to say
no english books
/resources/img/library_main.jpg

es_US
que decir?
no espanol books
/resources/img/library_main.jpg

fr_CA
Que dire
pas de livres francais
/resources/img/library_main.jpg

[/php]

XSL:
[php]

[/php]

Content XML:
[php]

templatedata/test/test/data/test.xml

[/php]

Adam Stoller

I sent this to you (Andy) via email - but I'll post it here too.

The point to keep in mind with respect to variables in XSLT is that they are not like variables in procedural languages (perl, java, etc.) but rather like variables in algebraic equations - taking on a [potentially] different value for each run - but not modifiable within a single run. That, and the fact that they are very tightly scoped.

I believe, given the example XML provided, that the following does essentially what you want:[html]

[/html]You might be able to condense it a bit, but I think the above provides a cleaner mechanism for scaling while maintaining readability.

One looks at the code and it seems to scream for making the replicant index number a variable so you could just set that and avoid all the extra verbiage - however that doesn't work as the variable will not get evaluated in string context and will instead always return 1 (true) indicating that the variable exists, rather than it's actual value.

Crsb

The point to keep in mind with respect to variables in XSLT is that they are not like variables in procedural languages (perl, java, etc.) but rather like variables in algebraic equations - taking on a [potentially] different value for each run - but not modifiable within a single run. That, and the fact that they are very tightly scoped.

I dont beleive that is the issue here. From what i see in the sample XML, locale is based on unique field in the DCR (Root/language), so i dont see How the locale would change in a single run.

I believe, given the example XML provided, that the following does essentially what you want:[html]

[/html]You might be able to condense it a bit, but I think the above provides a cleaner mechanism for scaling while maintaining readability.

do you have to hard-code the replicant index?
as you already know the replicants can be moved up and down which changes the index of a container. there is also a chance that the user might add a container for "fr_CA" any where in the DCR, it could be in top (1), middle (2)... there is nothing that restricts the user to maintain the order.

One looks at the code and it seems to scream for making the replicant index number a variable so you could just set that and avoid all the extra verbiage - however that doesn't work as the variable will not get evaluated in string context and will instead always return 1 (true) indicating that the variable exists, rather than it's actual value.

I am not sure if i understand this part, I know variables in XSL get evaluated in string context.

Finally, I thought Andy is trying to get this to work in SP, does that XSL code work in SP?

nipper

Yes this is for SP. I was torn as which forum to use as this was a SP page reading a DCR. That is why I used the Forms Pub forum and made an example that was XML/XSL only. I figured if it worked with FP then I could get it to work with SP.

I do not like the 2 solutions Adam and I came up with. Since it is only a hand full of variables and a couple languages, hard coding things can work. However I will certainly try your code, that will not require an XSL change to add a language. I cannot believe this is difficult. Yet another reason to dislike XSL.

I certainly appreciate the help from everyone, I will post my final code when I am done.

Andy

Adam Stoller

I dont beleive that is the issue here. From what i see in the sample XML, locale is based on unique field in the DCR (Root/language), so i dont see How the locale would change in a single run.

The locale wasn't changing - but all the other variables were trying to be changed based on the locale - hence the problem of the original approach that Andy was trying.

do you have to hard-code the replicant index?
as you already know the replicants can be moved up and down which changes the index of a container. there is also a chance that the user might add a container for "fr_CA" any where in the DCR, it could be in top (1), middle (2)... there is nothing that restricts the user to maintain the order.

I agree that it's sub-optimal but since XSL variables don't get evaluated within select attributes you either need to do that - or you need to provide another mechanism for ensuring you are choosing the correct items (perhaps putting a language attribute into each instance of the replicant such that you could use an xpath query to find the right one?)
Doh! - that information is already there - I somehow missed it last night when I was playing around with the code - and seeing that, and looking at what you posted - it's definitely a cleaner approach.
(the rest of this is just to complete the response to the response)

I am not sure if i understand this part, I know variables in XSL get evaluated in string context.

Neither variables nor params get evaluated as strings in a select attribute context. Go ahead and try something like:[html]

[/html]It will look like it does the right thing if locale is set to "en_US" - but you'll see that it does not do the right thing is you set it to "es_US" or "fr_CA" - because $idx, within the select attribute string, will always evaluate to "1" (true).

Finally, I thought Andy is trying to get this to work in SP, does that XSL code work in SP?

Perhaps - but the XSL I wrote was to deal with parsing the XML that was provided - which it does, just not as optimally as it could have (why I didn't see that inner language element I have no idea)

Crsb

Neither variables nor params get evaluated as strings in a select attribute context.
...It will look like it does the right thing if locale is set to "en_US" - but you'll see that it does not do the right thing is you set it to "es_US" or "fr_CA" - because $idx, within the select attribute string, will always evaluate to "1" (true).Perhaps - but the XSL I wrote was to deal with parsing the XML that was provided - which it does, just not as optimally as it could have (why I didn't see that inner language element I have no idea)

Sorry, i misread your statement, i thought you meant the evaluation in "test"... you are right about using variables to construct xpath/dynamic xpath.
Just to share:
Saxon has an extension to build xpath on run time, see this. if you use java (external task) to generate/regenerate pages in teamsite then you can use any transformer, so using saxon with the mentioned extension might help get around this limitation Smiley Happy

.
Merry xmas!

nipper

Just to finish up, I was able to use the code posted by Crsb. Thanks, this is much more portable than what I had.

Andy

Bhargav Coca

I know this is failrly out of date post, but this is the only one which was returned to be while i was searching for anything involving replicant index xslt,
Though this didn't answer my question to the point, I thought i would post it here any ways as it is little relevant. All I was trying to to find the last instance of my loop and use when and otherwise to process it, as shown in code snippet below. but its doesn't like it can anyone point my mistake.

[html]

[/html]

Thank You

Migrateduser

Try this way..

[HTML]

<li class="full">

[/HTML]

Cheers!
Navid Khan.

Rick Poulin

To explain Naveed's answer, your code was checking whether the last "links" child of each "links" element exists.. meaning you were looking for children rather than at the current element (and your check is probably not what you were looking for anyway).

Naveed's answer is equivalent to test="./position()=./last()", meaning it checks the current loop iteration element's position property (index into an array) against the last available index in that array.

Bhargav Coca

Sorry guys I found the solution as soon as posted the problem, just a quick brush up of xslt gave me the what i needed i was also looking for getting last item and also which is odd.

so position() = last() and postion() mod 2 = 1 gives me what i needed.

Thank You